Apparatuses, methods and systems for ad-hoc applications based on advertisement

ABSTRACT

The disclosure details the implementation of apparatuses, methods and systems for a Framework for Ad-hoc Applications Based on Advertising (FAABA). The FAABA may employ short-range radio-frequency communications. The disclosure teaches mechanisms for providing targeted advertising in connection with ad-hoc applications/point-to-point (P2P) communications between user terminals. In a manner, the invention teaches general collection components for user terminals, which is responsible for collecting and maintaining a dynamic set of advertisements as a background operation. This allows the user terminals to initiate applications that are based on P2P communication, and furthermore, allows collections of pre-loaded advertisements to be provided to the user terminals along and/or during the P2P communications. Also, the FAABA teaches that after advertisements are stored in the receiving device, the advertisements can be tailored more closely to the interests of the user of the device and the advertisements can be filtered based on current context of the user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/916,376 filed Jun. 12, 2013, which is a continuation of U.S.application Ser. No. 11/096,188, filed Mar. 31, 2005, the contents ofwhich are incorporated herein by reference in their entireties.

FIELD

The present invention relates generally to an apparatus, method andsystem to distribute information across a wireless communicationsnetwork. More particularly, the disclosed invention relates to anapparatus, method and system to distribute information across wirelessad-hoc networks among transient and mobile peer devices.

BACKGROUND Peer-To-Peer Communications (P2P)

People frequently use peer-to-peer (P2P) applications on personalcomputers to facilitate the distribution of information and computingresources. A basic P2P solution provides each client, e.g., a personalcomputer, on a network with both a server and client application thatallows each user to respectively make available and access resources(e.g., files, CPU time, memory, etc.) with other users. As such eachcombined client and server node on a P2P network is referred to as apeer. Examples such as Kazaa, Gnuetella, Morpheus, and Napster networksevince the public's desire to share files in a distributed fashion.

Network

Networks are commonly thought to consist of the interconnection andinteroperation of clients, servers, and intermediary nodes in a graphtopology. It should be noted that the term “server” as used hereinrefers generally to a computer, other device, software, and/orcombination thereof that processes and responds to the requests ofclients, often from across a communications network. The term “client,”in turn, generally refers to a computer, other device, software, user,and/or combination thereof that generates requests for service.Generally, the term “client” and “user” are interchangeable, and areused as such throughout. As such, servers serve their information torequesting clients. A computer, other device, software, or combinationthereof that facilitates, processes information and requests, and/orfurthers the passage of information from a source user to a destinationuser is commonly referred to as a “node.” Networks are generally thoughtto facilitate the transfer of information from source points todestinations.

SUMMARY

Although P2P protocols have been used as delivery mechanisms for sharingfiles, they have not been tailored to act as a delivery system formobile devices. Currently P2P nodes address one another logically byusing TCP/IP addresses. Such networks have no sense of geographiclocation, and do not account for in transit devices that frequently aredisconnected from any globally addressable and accessible network. Nosolutions exist where advertisements are preloaded for allowingadvertising content to be provided during communication betweenad-hoc/P2P network nodes. As such, the present disclosure teaches a P2Psystem that employs transient mobile devices as a delivery target andcarrier for content interchange, i.e., in particular for advertising.Further, transmission bandwidth is saved as no advertisements aretransmitted over the air when performing P2P communication with a nearbydevice.

In one embodiment of the present invention, a method is taught todistribute content during point-to-point communications. The methodincludes receiving advertisements on a mobile device from encounteredcommunication sources and storing the advertisements in an advertisementbuffer on the mobile device. The method also includes receiving anadditional communication from a nearby mobile device and displayingadvertisements along with the communication on from the advertisementbuffer based on advertising placement information on the mobile device.

In another embodiment, a system is taught to distribute content duringpoint-to-point communications. The system includes means to receiveadvertisements on a device from encountered communication sources andmeans to store the advertisements in an advertisement buffer on thedevice. The system also includes means to receive a communication fromanother device, means to display the received communication, means toretrieve an advertisement from the advertisement buffer on the device,and means to display the advertisement.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate various non-limiting, exemplary,inventive aspects in accordance with the present disclosure:

FIG. 1 is of a mixed data and logic flow diagram illustratingembodiments of a Framework for Ad-hoc Applications Based on Advertising(FAABA) topology;

FIG. 2 is of a data flow diagram illustrating embodiments of anapplication information distribution with an ad-buffer;

FIG. 3 is of a mixed data and logic flow diagram illustratingembodiments of an FAABA information distribution between a contentserver, an access point and user terminals;

FIG. 4 is of a mixed data and logic flow diagram illustratingembodiments of an FAABA information distribution between two userterminals; and

FIG. 5 illustrates embodiments of advertising display during FAABAcommunications.

The leading number of each reference number within the drawingsindicates the first figure in which that reference number is introduced.As such, reference number 101 is first introduced in FIG. 1; i.e.,reference number 201 is first introduced in FIG. 2, etc. Also, it shouldbe noted that dashed boxes in the figures are indicative of optionalembodiments. Solid lines indicate logic flow, while dashed arrowsindicate data flow.

DETAILED DESCRIPTION

A Framework for Ad-hoc Applications Based on Advertising (FAABA) istaught by showing topologies (FIG. 1), an application in an exampletopology (FIG. 2), logic for initial distribution of content (FIG. 3),and logic for distribution as between peers (FIG. 4). The FAABA providesa system that allows for dynamic distribution of content across looselyconnected, transient and mobile peer devices. While the FAABA isgenerally discussed throughout this disclosure in the context ofdistributing advertising, it should be noted that almost any kind ofcontent and/or information may be distributed by employing the FAABA;for example, in one embodiment the FAABA may be used as a P2P filesharing network. In a manner, the invention teaches general collectioncomponents for user terminals, which is responsible for collecting andmaintaining a dynamic set of advertisements as a background operation.In one embodiment, the collection component may be installed to themobile terminal during initial software installation within themanufacturing process, or it may be installed to the terminal asoperator software when a user of the mobile terminal subscribes tooperator services or even later on as freely distributable software. Inanother embodiment, the component is embedded within ROM and made partof the terminal hardware. In another embodiment, such “ad aware”components are distributed freely in the form of software.

Framework for Ad-Hoc Applications Based on Advertising

FIG. 1 is of a data flow diagram illustrating embodiments of informationdistribution in a FAABA topology. Generally, data flows between threeactors: user 131, 132 terminals 101, 102, access points 111, 112, andcontent servers 121. Users are generally, but not necessarily, humanbeings. In some contexts, users may be seen as vehicles and/or othersystems. For example, an automobile may be a carrier for terminals.Terminals are devices capable of processing information (e.g., having acomputing processor) and capable of forming and engaging incommunications in ad-hoc networks. Examples of terminals may include:laptops, personal digital assistants (PDAs), wireless telephones, and/orthe like. Such devices may employ any number of communication networkinterfaces; examples may include: Bluetooth (BT), cellular (e.g., basestation controller to base transceiver station (BTSM), code divisionmultiple access (CDMA), (enhanced) general packet radio service((E)GPRS), global system for mobile telecommunications (GSM)),satellite, WiFi, Ultra Wideband (UWB) and/or the like. The terminalshave memory and are capable of supporting applications and provide anoperating system environment allowing for the execution of suchapplications. In one embodiment, a Java runtime is provided, whichallows for the deployment of varied applications on the terminal device.One example of a terminal device is the Nokia® 9500 Communicator, whichis capable of engaging BT, cellular and WiFi communications. Typically,users carry and employ terminals for purposes of executing applicationsand communicating. Access points (AP) 111, 112 typically act ascommunications gateways across communications networks 113 such as theInternet. Examples of APs include BT and WiFi hotspots. The APs includebuffer memories to store ads that are provided by an ad server 121. Inone embodiment, an AP is comprised of a personal computer running theLinux operating system having a network interface, e.g., 802.11g, with aRAM and hard disk storage space allowing which may be used as a buffer.The ad server 121 may be connected to a communications network and isdisposed in communications with the APs. According to non-limitingembodiments of the present invention, the ad server may operated by aphone manufacturer, a cellular network operator, or by a third party,wishing to derive revenue by placing ads on the behalf of advertisers.Such operators may charge advertisers flat rates, a charge per viewedimpression, and/or the like. The ad server may have an ad serverdatabase with tables regarding the various APs by providing each AP witha unique identifier, e.g., its IP address. Further, the ad server mayhave various tables describing ads, ad use, advertiser clientinformation, user terminals and/or the like.

The upper portion of FIG. 1 shows users A 131 and B 132 at an initialtime A 133. Each user A and B, respectively, carries a terminal device101, 102, e.g., a BT enabled cell phone, and passes by an AP 111, 112.As user A's 131 terminal A 101 passes by AP A 111, terminal A 101engages in communications with AP A 111. Upon establishingcommunications, AP A provides advertisement A 141 to terminal A 101,which is stored on the device as a background operation and may beviewed by user A 131 upon user request. Similarly, as user B's 132terminal B 102 passes by AP B 112, terminal B 102 engages incommunications with AP B 112. Upon establishing communications, AP Bprovides advertisement B 142 to terminal B 101 as a backgroundoperation, which is stored on the device and may be viewed by user B 132upon user request. At time A 133, terminal A an B are too far apart tobe in direct communications with one another. As such, terminal A willnow have ad A and terminal B will now have ad B stored in its memory.

The lower portion of FIG. 1 shows users A 131 and B 132 forming anad-hoc network 123 at a subsequent time B 166, e.g., a BT pico-net. Asusers A 131 and B 132 approach and pass each other, their terminaldevices 101, 102 may establish a connection with one another forming thead-hoc network 123. As the users pass by one another, ad A 141, which isstored on terminal A 101, is sent to terminal B 102 as a backgroundoperation. Similarly, ad B 142, which is stored on terminal B 102, issent to terminal A 101 as a background operation. As such, bothterminals A 101 and B 102 both store ads A 141 and B 142.

According to embodiments of the present invention, the terminal devices101, 102 may conduct in a wireless communication session by way ofstarting a peer-to-peer communication application as the users pass byone another. During the communication session, when messages arecommunicated between the devices, the stored ads A 141 and B 142 may beincluded in the received message by either or both of the terminaldevices 101, 102 so that the ads A 141 and/or B 142 received asbackground operation will be displayed along with the peer-to-peercommunication if certain criterion for displaying either or both of theads A 141, B 142 is met, as will be described more fully below.

FAABA Applications

FIG. 2 is of a data flow diagram illustrating embodiments of anapplication information distribution with an ad-buffer. As mentioned inFIG. 1, an ad-buffer 205 is memory space allocated for the storage ofads on a terminal device 101 and access point 111. As long as theterminal and AP have a accessible memory (e.g., (flash) RAM, hard diskspace, etc.) and a programmable processor (e.g., an ARM processor with aJava runtime), then space may be allocated for the storage of amultitude of information types, including ads. In one embodiment, adsare provided in audio (e.g., .WAV, .MP3, .AAC, etc.), text (ASCII, HTML,XML, Unicode, etc.), graphic (e.g., .JPG, .GIF, .TIF, .PDF, etc.),multimedia (e.g., Flash), video (e.g., .AVI, .MPEG, .MOV, etc.), and/orthe like formats. The ads may be transported employing to and from theterminals and APs by employing HyperText Transport Protocol (HTTP) POSTcommands. The HTTP commands may be layered and employed over anyunderlying low level transport protocol (e.g., BT, cellular, satieties),for example, by employing TCP/IP over the lower-level communications.

As such, FIG. 2 illustrates an example of a user 101 that is movingabout a geographical region as depicted by the map 210. As the usermoves about the region from points A 215, B 220, C 225 and D 230, theuser passes by various access points and other ad-aware terminals andthereby collecting four advertisements; i.e., in this example one fromeach location. In this case, the user first received an ad for NYT Ale250 at location A, espresso 245 at location B, happy hour 240 atlocation C, and SafroCola at location D. Each of these ads were storedinto the ad-buffer 205 of user A's 131 terminal device 101. Each of thelocations represents terminal A 101 making an ad-hoc network 123 acrosswhich it received ads into its ad buffer 205 a.

The terminal 101 may be used for any number of applications 275. Exampleapplications may include: instant messaging, social network messaging,mail, Web surfing and/or the like. The terminal's 101 memory may beloaded with such applications as desired by the user 131. In oneembodiment, such applications include a portion of the display to showad-banners, e.g., similar to how the ad-based version of the Opera Webbrowser provides an advertising banner. In another embodiment, the admay be appended to incoming content. For example, incoming and out goingemails may have ads appended to the end of the message. In yet anotherembodiment, audio ads may be played upon receipt. Audio ads may also beused as alternative ring-tones.

In yet another embodiment, an instant messenger program 275 (e.g., AOL,Yahoo, etc.) may be used by the user 131 on the terminal device 101. Theinstant messenger program may also employ an ad-strip 288 into whichbuffered 205 a ads 235 are loaded and presented to the user. Ads may beresized to fit within the bounds of the ad-strip 288 as may be required.In such an example, when user A 131 and B 132 come within proximity ofone another, their terminals 101, 102 establish an ad-hoc network 123.At that point, user B 132 may choose to execute the terminal B's 102instant messenger 275 b and send a message “Hi!” 290 b. That chatmessage is sent to user A's terminal A 101 where it is displayed 290 aby terminal A's instant messenger 275 a on the terminal's display 298.Here, the instant messenger 275 a has an integrated ad-strip 288 whereit loads in an ad 245 from terminal A's ad buffer 205 a, which in thisexample was cached in the buffer at location B 220 earlier in the day.Similarly, if user B′s instant messenger 275 b were enabled with an adstrip 288, then could display ads collected from its own ad buffer 205b.

FAABA Terminal-Ap Ad Transfers

FIG. 3 is of a mixed data and logic flow diagram illustratingembodiments of an FAABA information distribution between a contentserver 121, an access point 111 and user terminals 101, i.e.,terminal-AP ad transfers. When a user moves their terminal 101 withinproximity 303 of an access point 111, the terminal will beginestablishing a connection with the detected access point 305. Regardlessof the transport mechanism (e.g., cellular, BT, WiFi, etc.), often, bothterminals and access points (e.g., cellular towers, BT APs, WiFirouter/APs, etc.) broadcast their availability by employing theirrespective transport protocols and establish connections employing knownconnection handshake protocols. As such, an AP 111 may form acommunication connection with the proximal terminal 101 by concludingthe handshake 319. In an optional embodiment, upon establishing aconnection, the terminal and/or AP may store the identifier (e.g., name,handle, address, etc.) of the other device with which it establishedcommunications; such identifiers may be stored in the devices' database(as will be discussed in greater detail below). Once the connection isformed 309, 319, the AP may determine if the terminal is ad aware 321.In one embodiment where BT is employed, a service discovery protocol(SDP) may be used to obtain profile(s) stored in memory on the terminals(e.g., generic object exchange profile (GOEP), service discoveryapplication profile (SDAP) compliant profiles, etc.). The profiles mayinclude an entry that identifies that the device with a flag signifyingthat the device is ad-aware, i.e., that it has components to enable thetransfer/interchange of ads between a terminal and either an AP oranother terminal. For example, with BT, a BT protocol stack componentmay include various protocols that enable the file transfer. In anotherembodiment, TCP/IP may be used as a transport layer where HTTP POSTcommands can transfer ad files as between terminals and APs. Similarly,technologies such as Apple's Rendezvous may be employed to provideprofiles of devices across TCP/IP enabled networks, e.g., across ad-hocIEEE 802.11 (WiFi) networks. If the terminal 101 is not ad aware, thencommunications may proceed normally without any further terminal-AP adtransfer activity 322.

If the terminal device is ad aware 321, the AP may request a catalog ofads and ad placement information 323 stored in the terminal's ad buffer.In one embodiment, the ad buffer is comprised of a database and suchrequests are made by way of a query request, e.g., via SQL commandsselecting for all ads on that device.

Moving temporarily from the terminal-AP transfer discussion, it isuseful to describe an example of an ad buffer database. An ad bufferdatabase (ABDB) may be embodied in a database and its stored data,wherein the database comprises stored instruction signals, which may beexecuted by the device's CPU to store and retrieve data; the storedinstruction signal portion configuring the CPU to process the storeddata. Ideally the database is a conventional, fault tolerant,relational, scalable, secure database such as HanDBase, Oracle (e.g.,8iLite Optimized Object-Relational database), thinkDB, and/or the like.Relational databases are an extension of a flat file. Relationaldatabases consist of a series of related tables. The tables areinterconnected via a key field. Use of the key field allows thecombination of the tables by indexing against the key field; i.e., thekey fields act as dimensional pivot points for combining informationfrom various tables. Relationships generally identify links maintainedbetween tables by matching primary keys. Primary keys represent fieldsthat uniquely identify the rows of a table in a relational database.More precisely, they uniquely identify rows of a table on the “one” sideof a one-to-many relationship. Alternatively and/or in environmentswhere processing power and memory are limited, the Bluetooth directorydatabase may be implemented using various standard data-structures, suchas an array, hash, (linked) list, struct, table, and/or the like. Suchdata-structures may be stored in memory and/or in (structured) files.Portions of databases, e.g., tables, may be exported and/or imported andthus decentralized and/or integrated. In one non-limiting exampleembodiment, the database module includes tables such as but not limitedto a (e.g., Bluetooth): identifier (e.g., a Bluetooth address) table,name (e.g., a cleartext name to represent a Bluetooth enabled device)table, profile(s) (e.g., generic object exchange profile (GOEP), servicediscovery application profile (SDAP) compliant profiles, etc.) table, adtable (e.g., storing the ads, ad identifier, current impression counts,etc.), ad placement information (e.g., storing ad target location,demographics, impression allotments, ad types, etc.), and/or the like.In one embodiment, the tables may be related by the an ad identifier keyfield entries as they are unique. In an alternative embodiment, thesetables may be decentralized into their own databases and theirrespective database controllers (i.e., individual database for each ofthe above tables may exist). By employing standard data processingtechniques, one may further distribute the databases over several devicesystemizations and/or storage devices. Similarly, configurations of thedecentralized database controllers may be varied by consolidating and/ordistributing the various database modules. The ABDB database may beconfigured to keep track of other (e.g., Bluetooth enabled) devices thathave passed within the range of the terminal as well as user requests,and/or other various transactions. The ABDB may communicate to and/orwith other components in a component collection, including itself, theoperating system, the file system, and/or facilities of the like. Thedatabase may contain, retain, and provide information regarding otherterminal devices and ad data. In an alternative embodiment, a Bluetoothidentifier field is added to a normal contact database (e.g., such asthose found in cellular telephones, PDAs, and/or the like) and linked tothe ABDB.

Now moving back to the discussion of terminal-AP transfers, upongenerating 15 a request for a catalog of ads in from the terminal's adbuffer and/or ABDB 323, the ad aware terminal 101 will generate a listof ads and current ad placement information (e.g., the number of timeseach ad has been viewed) from the ad buffer and provide that catalog tothe AP 307. The AP may use the obtained catalog 307 to update its ownimpression counts for the same ads stored on its own ABDB. For example,if the AP 111 determines that the 20 number of ad impressions for agiven ad has been exceeded, it may send a message to the terminal topurge such ads from the ad buffer 311. Upon updating its information 311with obtained terminal placement information 307, the AP may refer theads stored on the terminal 327. Several heuristics may be used. In oneembodiment, all new ads not found on the terminal, but available in theAP's ad buffer are transferred to the terminal 309. In such anembodiment, if there is insufficient memory, the terminal may deleteolder ads to accommodate the newer ads. In another embodiment, theterminal's profile information is analyzed for location, demographicfactors, and/or the like, and the AP selects ads for 5 refreshing basedon such factors 327. Such analysis may be achieved by parsing theterminal's profile and generating an SQL query based on token keywordsfrom the terminal's profile which act to select ads in the AP's ABDB,i.e., ad buffer.

This AP-terminal transfer facility 327 may then update a content server121 with regard to the updated ad usage/placement information obtained307 by the AP 329. The AP may provide its own profile information (e.g.,location, AP identifier, etc.), its current catalog of ads in its adbuffer (e.g., by selecting all ads in its ABDB), and its updated 325placement information, and send all such information to the ad server121, 339. Thereafter, the AP-terminal transfer facility 329 may iterate319 as other terminals come within its proximity. It should be notedthat the above embodiments show that the AP determines if a terminal isad aware 321, but, alternatively, the terminal may similarly determineif an AP is ad aware and take on the processing requirements forevaluating and requesting the refreshing 327 of ads; such an embodimenthas the benefits of distributing the processing load to a greater numberof terminals.

The content server 121 may obtain updated ad placement information(e.g., updated add impressions) 339 from an AP 111. In one embodiment,the AP may provide such updates when it culls updated information 325from terminals 111 as already discussed 329. Also, the ad server 121 mayperiodically poll APs to provide 329 their current ad buffer catalog andplacement information. In one embodiment, the ad server may specify a aniteration period in which updates 339 and ad refreshing are provided;for example, such updates may be periodically instantiated with a Unixcron job. Upon obtaining the updates 339, the ad server 121 may storethe updated information into its own ABDB 341. With the updates storedin the ABDB 341, the ad server may query itself to generate a list ofnew ads for a given AP. For example, upon updating the ABDB 341, certainads may have experienced more impressions than paid for by advertisers.In instances where the ads are no longer viable, either because the timeperiod in which they should run is no longer valid or the impressioncount has been exceeded, such expired ads will not be identified asrefresh candidates when the ad server generates a new set of ads 343.This may be achieved by 10 selecting ads keyed upon a given AP'sprofile. The AP profile may have demographic, geographic, and/or otheridentifying information which may be used as the basis of a an SQL queryof the ad server's ABDB. Further, such a query would also be limited tonon-expired ads. Upon supplying such a search query to the ABDB, it willreturn a list of candidate ads for refreshing 343. In many instances,the returned number of candidate ads may exceed the 15 capacity of theAP ad buffer, and as such, several heuristics may be employed forselecting the ads with which to refresh the AP ad buffer 345. In oneembodiment, the results with the highest matching index rankings areselected. In another embodiment, the matches where advertisers paid thegreatest amount for ad placement may be selected. Such selections arecut-off to fit within the ad buffer space of the AP. The ad buffer spacemay discerned from its 20 provided 329 profile. Upon selecting therefresh ads 345, they are provided 347 to the AP, which receives them331 and stores them in its ad buffer 333. The AP may purge older ads inits ad buffer in a manner similar to the purging of the ad buffer asalready discussed with regard to the terminal 311. The AP may separatelyiterate this receive 331 and refresh 333 operation on demand 347,periodically, and/or continuously. Similarly, the ad server 121 mayindependently iterate the receiving 335 of ads and placement information(e.g., desired target locations, demographics, impression allotment,price paid per impression, ad type, advertiser identifier, etc.) 334 andstorage of such information within its own ABDB 337.

In yet another independently iterating component, terminal A 101 willretrieve an ad from the ad buffer when accessing an ad aware program onthe terminal 313. An example ad aware application, an instant messenger275 a, was already discussed in FIG. 2. For a program to be ad aware, itneed only access the contents of the ad buffer 205 and display ads 315.For example, the ad aware application may display ads in an ad strip 288of FIG. 2. Upon displaying the ad 315, the impression count for the adis increased by one and record of it is stored in the ABDB 317.

Furthermore, the heuristics for selecting 313 which ad to display 315may vary. In most circumstances, ads that have been displayed beyond anallotted impression count (if known) or outside of a specified locationor time frame will not be selected for display. As impression countsincrease, or as the terminal's internal time monitor or positioningsensors (e.g., GPS) change, the terminal 101 may compare an ad'splacement information 334 against such dynamically varying circumstancesto act as a filter for selecting candidate ads for display 315. Forexample, various cell phones have the ability to discern their locationrelative to cell towers and can provide GPS coordinates. Alternatively,should a user find themselves proximate to an access point, or incommunication with another terminal that is proximate to an accesspoint, a geographic position may be discerned based on the access pointslocation. An example of this is when a user enters a retail outlet thatoffers WiFi connectivity, and their WiFi enabled device establishes aconnection at that location. As such, as part of the placementinformation, filtering queries may be provided. An example of suchfiltering would be an ad received for a coffee shop 235 that wouldinclude filtering that requests that the ad is only displayed if a user131 is within half a mile of the coffee shop's physical location. Insuch an example, the filter may include an XML tag delineated requestproviding the GPS coordinates of the coffee shot (e.g.,longitude/latitude) and a deviation amount of half a mile. Although suchan ad may have been transferred to terminal A 101 many miles away fromthe coffee shop location 220 by another terminal, it becomes displayed288 when the user 131 walks within a half mile of the shops location 220(e.g., by performing an arithmetic delta on the terminal's current GPSposition and seeing if it overlaps the supplied GPS coordinates of thecoffee shop 220). It should be further noted that also other typelocation information, such as, for example the cell ID of the basestation with which mobile terminal is currently communicating could beused to determine the location of the mobile terminal, Similarly,demographic filters may be employed. For example, if a user's terminaldevice profile includes personal information regarding the user (e.g.,age, sex, etc.), then ads may be targeted for exposure based ondemographics. For example, if the user is in a convenience store and theuser is known to be over 21 years of age, then ads for alcohol may beselected from the ad buffer. In another embodiment, the ads having thehighest payments per impression as paid by an advertiser are given thegreatest priority. As has already been discussed, such selection maytake place by parsing filters/placement information for constituentkeyword tokens and generating a query to perform on the terminal's ABDB.

FAABA Ad Transfers Between Terminals

FIG. 4 is of a mixed data and logic flow diagram illustratingembodiments of an FAABA information distribution between two 101 userterminals 102, i.e., terminal ad transfers. When a user moves theirterminal 101 within proximity 403 of another terminal 102, the terminalswill begin negotiating 410 a connection with on another 450. Regardlessof the transport mechanism (e.g., cellular, BT, WiFi, etc.), often, theterminals (e.g., cellular towers, BT APs, WiFi router/APs, etc.)broadcast their availability by employing their respective transportprotocols and establish connections employing known connection handshakeprotocols. In the instance of two peers, often the handshaking involvesestablishes one peer that acts as a server to the other peer acting as aclient. As such, terminal A 101 may form a communication connection withthe proximal terminal B 102 by concluding the handshake 450. Once theconnection is formed 450, terminal B 102 may determine if terminal A isad aware 455. In one embodiment where BT is employed, a servicediscovery protocol (SDP) may be used to obtain profile(s) stored inmemory on the terminals (e.g., generic object exchange profile (GOEP),service discovery application profile (SDAP) compliant profiles, etc.).The profiles may include an entry that identifies that the device with aflag signifying that the device is ad-aware, i.e., that it hascomponents to enable the transfer/interchange of ads between terminals.For example, with BT, a BT protocol stack component may include variousprotocols that enable the file transfer. In another embodiment, TCP/IPmay be used as a transport layer where HTTP POST commands can transferad files as between terminals. If terminal A 101 is not ad aware, thencommunications may proceed normally without any further terminal adtransfer activity 422.

If the terminal device is ad aware 455, terminal B may provide a catalogof its ads and ad placement information 460 stored in its ad buffer toterminal A 415. In one embodiment, the ad buffer is comprised of adatabase (as has already been discussed in greater detail in FIG. 3) andsuch requests are made by way of a query request, e.g., via SQL commandsselecting for all ads on that device. Similarly, terminal A 101 may makea determination of terminal B is ad aware 415. Once terminal Adetermines that terminal B is ad aware 415, it may make a request toobtain a catalog of ads in terminal B's ad buffer 420. If terminal B 102has not yet generated a catalog of its ad buffer contents 460, it woulddo so in response to terminal A's request 420 and provide the catalogback to terminal A 420. Terminal A may then compare the ad contents ofterminal B's ad buffer to the ad contents of its own ad buffer anddiscern the differences in contents 425. In one embodiment, the terminalmay use ad identifiers (e.g., unique numbers that identify ads from thead server database) as a basis for comparison. Upon identifying adsdifferent from its own stored in its ad buffer, terminal A 101 then maygenerate and provide a request for those different/new ads 430 toterminal B 102, which receives the request 465. In one embodiment,terminal A may also send an offer to supply ads in terminal A's adbuffer that are not in terminal B's ad buffer 102 so that terminal B maybe updated as well 465. Terminal B may then provide the ads requested byterminal A 470, e.g., by sending the ads via HTTP POST. Once terminal Aobtains the requested ads 435 it may check to see if terminal B wants toaccept terminal A's offer for ads 440. Terminal A may continue to waitfor a positive or negative response to its offer. In one embodiment,terminal A will continue to wait for a response to its offer 440 untilone is obtained. In another embodiment, terminal A will wait for aspecified time, and if it does not receive a response to the offer, sucha lack of response is interpreted as a declining of the offer. Inconcert, if terminal B approves of the offered ads 475, it will informterminal A of such approval (or disapproval, whichever the case). In oneembodiment, a terminal will accept all new ads. In an alternativeembodiment, a terminal may keep a log of viewed ads, and may declineoffered ads if such ads have already expired and been purged from theterminal in the past. After informing terminal A 475 of its 102 approvalof the offered ads, terminal A provides those ads 440 and terminal Bobtains the offered ads 480, e.g., via HTTP POST transfer. Uponobtaining requested/offered ads 435, 480, the terminals may store theads in their respective ad buffers and purge older as may be requiredand as has already been discussed 311 of FIG. 3. Finally, it should benoted that each of the terminals A and B 101, 102 may independentlyiterating retrieval 313, display 315, and impression counting of ads 317as has already been discussed in FIG. 3.

FIG. 5 illustrates embodiments of advertising display during FAABAcommunications. Further to the description of ads 288 being displayed315 during instant messaging 275 of FIG. 2, FIG. 5 shows a transcript530 of such a discussion as between 15 Terminal A 101 and Terminal B102. The two lightly dotted boxes 530 show the transcript of adiscussion between two users: User A 131 controlling terminal A 101, andUser B 132 controlling terminal B 102. The users are keying in theirmessages to one another by using an instant messenger program on theirterminals, and one can see the discussion develops over time from thetop of the figure to the bottom. Each of terminal A 101 and B 102 haveaccumulated various ads in their respective ad buffers 205, as hasalready been discussed in connection with FIG. 2. In particular, bothusers A 131 and B 132 have collected ads A 250, B 245, C 240 and D 235of FIG. 2 through various interactions; all of which are resident ineach of the terminals local ad buffers. Currently, user A is situated ata location between geographic points B 220 and D 230 of FIG. 2, whileuser B is situated at a location between geographic points A 215 and C225. The conversation starts with User B saying “Hi,” which is firstdisplayed on Terminal B 102, 535 b, and then on Terminal A 101, 535 a.After terminal receives the message 535 a from Terminal B, the ad-awareinstant messenger program loads an ad, e.g., for SafroCola 235, fromTerminal A's local ad buffer 205 and displays it in an ad strip 288 aspart of the on-going communications between users A and B. In this case,the ad-aware software used Terminals A's geographic position that isproximal to geographic location D 230 (e.g., which might be a locationthat sells SafroCola) as a reason to display an ad relevant to user A'sgeographic context. Next, user A sends a message 540 a back to user B540 b. When Terminal B receives the message 540 b from Terminal A,Terminal B's ad-aware instant messenger program, similarly, retrieves anad, e.g., for ale 250, from its local ad-buffer and displays the ad aspart of the messaging. Here, similarly, the ad-aware software usedTerminal B's geographic position that is proximal to geographic locationA 215 (e.g., which might be a location that sells Ale) as a reason todisplay an ad relevant to user B's geographic context. Here theterminals may have accessed memory containing the current GPScoordinates and then searched ads in its ad buffer that were tagged withGPS coordinates, and selected ads in the closest proximity to the user.User B may then continue on with the conversation 545 b, which wouldresult in User A receiving that message and observing anotheradvertisement relative to the users position, e.g., perhaps for a café245 near user A's position 220. And this may go back and forth with UserB continuing to retrieve ads from its ad-buffer and display ads based ongeographic and other contexts 240.

As the conversation progresses 550 b, we can see that Terminal A'sad-aware instant messenger is capable of using other contexts as a basisin for retrieving ads (e.g., from its local ad-buffer) and for display505. Here User B provided a message asking if User A might be interestedin “Cola” and Terminal A's ad-aware software searched for ads in itsad-buffer that were tagged with “Cola” and then retrieved a Cola ad 505.As such, the ad-aware software may the text of the communicationsbetween users to search for ads having matching terms. Ads having thegreatest number of matching terms would then be selected from thead-buffer and displayed. As the conversation continues 555 a, more ads510 based on communications context 555 b are displayed; e.g., User A'ssuggestion for ale 555 b would cause the ad-aware software to retrievean ale ad 510 from Terminal B's ad-buffer. At this point, we see whatthe users might see on their screens 298 as what is represented by thesolid boxes 298. In this example, rather than having a stationary adstrip 288 that occupies a fixed portion of the terminal's display screen298, instead, the banner ads are displayed in line 510, 245, 515, 520.As the conversation nears a close 565 a, Terminal B may display an ad245 based on the comments and suggestions received from User A 565 b;e.g., User A may have observed an ad 245, 545 a during the course of theconversation and suggest it as a place to visit 565 b and cause TerminalB to retrieve this ad 245 from its ad-buffer. As the conversation closesor continues other ads 520 may continue to be shown.

Several things should be noted about the example conversation in FIG. 5.First, as ads are displayed, the terminal's ABDB is updated noting whenand where the ad was displayed. As the ABDB is updated over time, suchad tracking may eventually be uploaded back to centralized servers thataggregate and track ad use for many terminals, which in turn may be usedfor setting ad rates. Next, Terminal A and B may be disposed incommunication through any number of modes and mediums. In some cases,the terminals may be far apart and each terminal may be communicatingthrough a local access point and the communications may take place overa long distance back bone, e.g., over the Internet. In other cases, thecommunications may be local short-range connections where the users aredisposed in communication over the same access point, e.g., cellular,Wi-Fi, Bluetooth, etc. Also, the nature of the communications may varydepending on the protocol and/or application used by the user; forexample, some communications may be direct (e.g., voice communicationsvia cellular towers) while others are peer-to-peer (e.g., instantmessaging). Further, it should be noted that even in the cases wherecommunications are over local-short range connections, each terminal mayaccess its own ad-buffer for the retrieval of ads. By each terminalaccessing its own ad-buffer for ads, communication bandwidth is saved asthe ads are not transmitted during the communication and the ads can bemore clearly targeted to the terminal users as the context assessment(e.g., filtering, matching, etc. of location, profiles, etc.) takesplace locally on the receiver's terminal. Also, although an instantmessaging program was described, many other applications may be madead-aware; e.g., email, SMS, audio, video, etc. For example, while usersconverse on their cell phones, the cell phone's display may be used toshow ads based on the user's location, conversation (e.g., caller ID ofa friend in their address book may suggest a gift because the friend'sbirthday is coming up soon), profile, etc.

It should be noted that the FAABA's operations discussed in FIGS. 1-5,above, take place as background operations so the user of the mobileterminal does not have to be aware of such operations. In an alternativeembodiment, users may be prompted for their approval to display theirpreference of ads, which may be used to further establish a userprofile.

The entirety of this disclosure (including the Cover Page, Title,Headings, Field, Background, Summary, Brief Description of the Drawings,Detailed Description, Claims, Abstract, Figures, and otherwise) shows byway of illustration various embodiments in which the claimed inventionsmay be practiced. In describing embodiments of the invention, in somecases specific terminology has been used for the sake of clarity,however, the invention is not intended to be limited to and/or by thespecific terms so selected, and it is to be understood that eachspecific term includes all technical equivalents which operate in asimilar manner to accomplish a similar purpose. It should be noted thatterms and or phraseology in this disclosure are not exhaustive indetail, and are not provided as definitive definitions. Rather, theterms are provided herein simply as an aid to the reader. The terms arenot limiting of the disclosure and/or claims herein. The use of theterms may contemplate any of the broader, and/or multiple meanings foundin common use, dictionaries, technical dictionaries, and/or in actualuse in the technical arts, as well as any broadening made throughoutthis disclosure. Also, the advantages and features of the disclosure areof a representative sample of embodiments only, and are not exhaustiveand/or exclusive. They are presented only to assist in understanding andteach the claimed principles. It should be understood that they are notrepresentative of all claimed inventions. As such, certain aspects ofthe disclosure have not been discussed herein. That alternateembodiments may not have been presented for a specific portion of theinvention or that further undescribed alternate embodiments may beavailable for a portion is not to be considered a disclaimer of thosealternate embodiments. It will be appreciated that many of thoseundescribed embodiments incorporate the same principles of the inventionand others are equivalent. Thus, it is to be understood that otherembodiments may be utilized and functional, logical, organizational,structural and/or topological modifications may be made withoutdeparting from the scope and/or spirit of the disclosure. As such, allexamples and/or embodiments are deemed to be non-limiting throughoutthis disclosure. Also, no inference should be drawn regarding thoseembodiments discussed herein relative to those not discussed hereinother than it is as such for purposes of space and reducing repetition.For instance, it is to be understood that the logical and/or topologicalstructure of any combination of any program components (a componentcollection), other components and/or any present feature sets asdescribed in the figures and/or throughout are not limited to a fixedoperating order and/or arrangement, but rather, any disclosed order isexemplary and all equivalents, regardless of order, are contemplated bythe disclosure. Furthermore, it is to be understood that such featuresare not limited to serial execution, but rather, any number of threads,processes, services, servers, and/or the like that may executeasynchronously, concurrently, in parallel, simultaneously,synchronously, and/or the like are contemplated by the disclosure. Assuch, some of these features may be mutually contradictory, in that theycannot be simultaneously present in a single embodiment. Similarly, somefeatures are applicable to one aspect of the invention, and inapplicableto others. In addition, the disclosure includes other inventions notpresently claimed. Applicant reserves all rights in those presentlyunclaimed inventions including the right to claim such inventions, fileadditional applications, continuations, continuations in part,divisions, and/or the like thereof. As such, it should be understoodthat aspects of the disclosure such as advantages, embodiments,examples, features, functional, logical, organizational, structural,topological, and/or other aspects are not to be considered limitationson the disclosure as defined by the claims or limitations on equivalentsto the claims.

What is claimed is:
 1. A method, comprising: determining proximity of afirst mobile client device and a second mobile client device, whereinthe first mobile client device is associated with a first user and thesecond mobile client device is associated with a second user;establishing a communication connection between the first mobile clientdevice and the second mobile client device; receiving data on the firstmobile client device from the second mobile client device through thecommunication connection; and causing, at least in part, a displaying ofthe data on the first mobile client device.
 2. The method of claim 1,wherein the communication connection is a handshake protocol.
 3. Themethod of claim 1, further comprising: determining stored data on thefirst mobile client device associated with the first user is not thesame as the data; and requesting additional data from the second mobileclient device, wherein the additional data is the data received from thesecond mobile client device that is not stored in the first mobileclient device.
 4. The method of claim 1, further comprising: determiningstored data on the first mobile client is not the same as the data;presenting updating data from the first mobile client device, whereinthe updating data is data stored on the first mobile client device thatwas not received from the second mobile client device; and receivingacceptance of the updating data by the second mobile client device. 5.The method of claim 3, wherein stored data includes currently storeddata, logged data representing previously stored and/or viewed data, ora combination thereof.
 6. The method of claim 1, further comprising:causing, at least in part, storage of the data in a buffer on the firstmobile client device; and deleting previously stored buffer data basedon a determination of whether space is needed to store the data in thebuffer.
 7. The method of claim 1, wherein the data is is provided in oneor more of an audio, graphical, multimedia, program, textual, and videoformat.
 8. An apparatus, comprising: at least one processor; and atleast one memory including computer program code, for one or moreprograms, the at least one memory and the computer program codeconfigured to, with the at least one processor, cause the apparatus toperform at least the following: determine proximity of a first mobileclient device and a second mobile client device, wherein the firstmobile client device is associated with a first user and the secondmobile client device is associated with a second user; establish acommunication connection between the first mobile client device and thesecond mobile client device; receive data on the first mobile clientdevice from the second mobile client device through the communicationconnection; and cause, at least in part, a displaying of the data on thefirst mobile client device.
 9. The apparatus of claim 8, wherein thecommunication connection is a handshake protocol.
 10. The apparatus ofclaim 8, further comprising: determine stored data on the first mobileclient device associated with the first user is not the same as thedata; and request additional data from the second mobile client device,wherein the additional data is the data received from the second mobileclient device that is not stored in the first mobile client device. 11.The apparatus of claim 8, further comprising: determine stored data onthe first mobile client is not the same as the data; present updatingdata from the first mobile client device, wherein the updating data isdata stored on the first mobile client device that was not received fromthe second mobile client device; and receive acceptance of the updatingdata by the second mobile client device.
 12. The apparatus of claim 11,wherein stored data includes currently stored data, logged datarepresenting previously stored and/or viewed data, or a combinationthereof.
 13. The apparatus of claim 8, further comprising: cause, atleast in part, storage of the data in a buffer on the first mobileclient device; and delete previously stored buffer data based on adetermination of whether space is needed to store the data in thebuffer.
 14. The apparatus of claim 8, wherein the data is is provided inone or more of an audio, graphical, multimedia, program, textual, andvideo format.
 15. A non-transitory computer-readable storage mediumcaning one or more sequences of one or more instructions which, whenexecuted by one or more processors, cause an apparatus to at leastperform the following steps: determine proximity of a first mobileclient device and a second mobile client device, wherein the firstmobile client device is associated with a first user and the secondmobile client device is associated with a second user; establish acommunication connection between the first mobile client device and thesecond mobile client device; receive data on the first mobile clientdevice from the second mobile client device through the communicationconnection; and cause, at least in part, a displaying of the data on thefirst mobile client device.
 16. The non-transitory computer-readablestorage medium of claim 15, wherein the communication connection is ahandshake protocol.
 17. The non-transitory computer-readable storagemedium of claim 15, further comprising: determining stored data on thefirst mobile client device associated with the first user is not thesame as the data; and requesting additional data from the second mobileclient device, wherein the additional data is the data received from thesecond mobile client device that is not stored in the first mobileclient device.
 18. The non-transitory computer-readable storage mediumof claim 15, further comprising: determining stored data on the firstmobile client is not the same as the data; presenting updating data fromthe first mobile client device, wherein the updating data is data storedon the first mobile client device that was not received from the secondmobile client device; and receiving acceptance of the updating data bythe second mobile client device.
 19. The non-transitorycomputer-readable storage medium of claim 18, wherein stored dataincludes currently stored data, logged data representing previouslystored and/or viewed data, or a combination thereof.
 20. Thenon-transitory computer-readable storage medium of claim 15, furthercomprising: causing, at least in part, storage of the data in a bufferon the first mobile client device; and deleting previously stored bufferdata based on a determination of whether space is needed to store thedata in the buffer.